COMMENT ⊗   VALID 00011 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00003 00002	∂08-Sep-77 1342 LES	Dialnet blurb & Bell modem
C00005 00003	∂08-Sep-77 1357 JMC	More on modems
C00006 00004	∂09-Sep-77 2008 DGR	Interested in what you have on Dialnet
C00008 00005	∂14-Oct-77 1222 JMC	Bell Labs visit.
C00009 00006	∂28-Sep-77 0014 JMC	(To Sproull)
C00010 00007	∂15-Oct-77 2018 MRC	DIALnet with multiplexed connections
C00012 00008	∂15-Oct-77 2355 JMC	(Answer to RMS)
C00014 00009	∂27-Oct-77 1437 Bob Sproull at CMU-10A	DialNet comments
C00025 00010	∂30-Oct-77 1918 MRC	DIALnet mail formats
C00029 00011	∂31-Oct-77 1153 MOON at MIT-MC	Dialnet mail protocol
C00035 ENDMK
C⊗;
∂08-Sep-77 1342 LES	Dialnet blurb & Bell modem

On the short Dialnet blurb, if it intended for external publication, I
think the sections that use first person plural should be changed to third
person.  If you would like me to hack it along those lines, give me a
pointer.

I heard from the Telco modem guy, who is Jim Burnett, (56) 291-5143.
Their 1200 baud modem is called the 202S and is available, on 3 weeks
notice, at a cost of $75 to install plus $45/month.  I think we would also
want the reverse channel feature ($5.50/mo.)  and the 801 Calling Unit
($26/mo.).  There is no additional installation charge if these are on the
initial order.

So it looks like the cost is $75 installation plus $76.50/month.

∂08-Sep-77 1357 JMC	More on modems

Please improve the short Dialnet blurb as you proposed.  Let's wait on the
modem till we see the Vadic literature which is being mailed, but let's
plan to go ahead with one or the other promptly.  We also need new dialers
at each end.  Vadic sells them and Telco rents them.  I want a separate
dialer for Dialnet, because the program should be a package, and the using
the other dialer would mean that the program would have to take into
account other uses of the dialer.

∂09-Sep-77 2008 DGR	Interested in what you have on Dialnet

I am the Networks and Communications Working Group Chairman for DEC-10/20
DECUS.  Many of the DECUS members are interested in Dialnet concepts and
the possibilities of forming networks.  John McCarthy at one point asked
DECUS, through me, to help with Dialnet as if it were a joint venture
though Stanford would have the NSF funding.  I have now found out that you
have gotten quite a head start on things.  I would still be interested in
keeping in touch with what you are doing, and if the DECUS organization
can help in some way, let me know.  Our Fall meeting will be in San Diego
November 28-December 1 and that is a good forum for rallying support.

By the way, Keith Gorlen and I have developed a quite similar system for
DEC-10/20 and PDP-11 that we call CLINK.  It permits virtual terminal mode
connections and file transfer of all varieties.  I had hoped that JMC
would have let me know early enough that I could suggest that parts of
Dialnet that are the same build upon the CLINK base which we have
developed quite thoroughly.  .....Glenn

∂14-Oct-77 1222 JMC	Bell Labs visit.

R.C. Prim who is in charge of some area of communications research at Bell
Labs called and said that they are quite interested in Dialnet and that he
and Max Mathews (whom we know well) and Sandy Fraser want to visit next
month.  Max will call to make arrangements.  Mark, please put a copy of
your latest on Patte's desk to be sent to Prim for them to think about.

∂28-Sep-77 0014 JMC	(To Sproull)

Bob, We have an NSF grant to develop Dialnet - protocols for giving
ARPAnet like facilities to users of telephones.  We should have
preliminary protocols in a few months.  The initial test machines will be
SAIL and LOTS, a DEC-20 at Stanford for teaching and unsponsored research.
Since it is a standard DEC-20, the programs will be immediately usable by
Caltech if theirs is likewise standard.  Various files in [DIA,JMC] are
relevant.  The man doing the work is Mark Crispin who is called MRC here.
He has some preliminary documentation in some files.
John

∂15-Oct-77 2018 MRC	DIALnet with multiplexed connections

Here are RMS' comments about multiplexed connections, which Les said was a
bad idea.  Do you have an answer to this?

RMS@MIT-AI 10/15/77 14:36:32 I think that you will be screwd considerably
in the future if you don't allow NOW in the host-host protocol for
multiplexed connections.  You can make it optional for a host to implement
them.  But there is no reason why a big central server shouldn't implement
them when talking to another big machine.  Just add a new error code "I
can't handle two connections at once" and say that it is legitimate to
complain that way to a second RPC.  The large computer, getting that
response, could make the requesting process wait for the existing
connection to close.  A small computer would presumably not try to use two
connections at once, so if it got that reply it would send a Reset and try
again.  Doing things this way means that small machines don't have to be
burdened with multiple connection hair but as they grow they can expand
into it whenever their hackers think it's worth it.  Also, there are
already 9600 baud modems - expensive, it is true.  But do you want DIALNET
to be obsolete in 5 years?

∂15-Oct-77 2355 JMC	(Answer to RMS)

The voice network doesn't allow multiplexed connections, because the
probability that two users will be talking to the same other place is low.
After Dialnet is well established, there will be a great variety of places
to which people talk.  Having several Dialnet ports will therefore be of
greater priority for a large system than making one port handle several
connections at once.  All this depends to some extent on how much trouble
it is to implement multiple connections, and how much difficulty providing
for multiple connections makes for inexperienced system programmers who
only want to implement single connections.

∂27-Oct-77 1437 Bob Sproull at CMU-10A	DialNet comments

Sorry that I have not come through with DialNet comments earlier, but here
they are.  Rather than argue with items directly, I have chosen instead to
offer a counter-offer, and see what you think.

1. (In the file Dialne.Mem, the NSF proposal).  It seems to me that one
implication of the "phone number" view of the world is that the naming
scheme for "sites" may often use literal numbers.  Thus, in the example of
smith returning a message (page 4) that includes a pointer to
DAVE@UTEX-CHEM3, it would probably have been better practice to couch the
pointer in fully literal form such as DAVE@512-471-3222 or whatever the
number is.  Thus, it doesn't depend on the recipient's having the proper
address.

2.  It seems to me that DialNet should primarily be kept EXTREMELY simple
so that home terminals and modest computers can implement it, and also so
that ordinary mortals reading documentation and trying implementations
encounter as few surprises as possible.

To that end, it seems to me that an individual circuit (i.e., the
connection made by one computer dialing another) should NOT be further
packet-multiplexed.  That is, a computer should call another, transmit a
single file, and hang up.  Or, if several files are to be transmitted, it
calls up, transmits file 1, transmits file 2, and then hangs up.

The whole point is to let the telephone equipment do the switching.
Someday, DialNet may even use communication services that are actually
implemented with packet switching, or whatever.  But the separate
communicating computers need not be concerned with that -- it's a
communications issue.

Now I realize that this proposal screws up two things:  (1) TELNET-like
use of DialNet by multiple users over one communications circuit, and
consequently (2) your own desires to help SU-AI and LOTS communication.  I
guess I believe that remote login is worth a separate connection
(particularly at the speeds we are talking about), and that little will be
gained by protocol to multiplex the connection in a fine-grained way.

So my model is best thought of as a file-transfer facility.  One computer
calls another, and sequentially transmits each file it has for the
partner, and hangs up.  Very simple.

3. Starting the connection.  I think you should think a little about
automatic speed recognition preceeding the transmission, as there are
pretty good ways of doing this, and it avoids having to keep an up-to-date
directory of everyone's modem speeds.

Then, it seems to me you ought to make provision for detecting 2 modes of
connection: from another computer (C) or from a person (P) using a
terminal.

The point of the person-mode is that some computers may be willing to
implement an interactive system for people who own only terminals to enter
files or mail for users at the site, or for forwarding elsewhere.
Individual sites can offer different interactive schemes for prompting for
messages, editing, limiting time "logged in", etc.  DialNet doesn't really
have to specify much, except how an answered phone call can be put in this
"mode." Clearly, a site does not have to implement such P facilities at
all.

So a connection might start with a speed-recognition character, or perhaps
some simple exchange to be sure everything is agreed (remember, a person
has to be able to do it).  Then comes a character to set the proper
"mode".  (All of this is in terms of asynchronous communications; for
synchronous stuff, you can assume it's not a P, and may even want to
assume you know the speeds.)

4. Now let's assume we're in C mode, and want to transmit some stuff.

First, you need a way of reliably sending a "chunk" (or packet) of
information, and getting some kind of a response.  I suggest something
simple:  herald character, followed by 3-char count, followed by that many
characters, followed by check sum.  Might use two different heralds, one
of which asks for a response.  I don't think the details of this
"reliable-chunk" mechanism are particularly important, but they should be
simple.  Note that addressing, and flow control are simply not needed.  It
might be nice, however, to be able to have two flavors of chunk:  COMMAND
and DATA.

Assuming we can transmit chunks, we can (1) define protocol schemes as
COMMAND chunk exchanges, and (2) implement streams of data as simply a
succession of DATA chunks.

Now let's look at a file transfer transaction.  We might like to have
three phases: (1) send file name, path, password, account etc. as free
text in a COMMAND chunk, and get some sort of response; (2) send the file
as a bunch of DATA chunks, provided the response to (1) was OK; (3) ask,
via some COMMAND exchanges, whether the entire transaction was OK. At any
time during these, the receiver might send a COMMAND chunk that aborts
things (out of file space, etc.)

The same scenario works for mail message transfer.  The initial phase
simply specifies a mail message comming.  The second phase is the text
(including all the header fields, etc.).  The final phase verifies that
the mail was received (e.g., no such local user, unable to forward, etc.)
A "smart" mail system could parse header fields during phase 2, as the
message arrives, and issue an early abort if it is going to refuse the
mail.

Because COMMAND exchanges are relatively rare, they might as well be in
some simple free-text form, e.g.

COMMAND: File-transfer, FileName=<sproull>foo.dat, USER=Sproull, Password=eighty

 or

COMMAND: Abort, Comment=No such local user

These will certainly be easy to understand, and relatively simple to parse
(use very simple rules:  phrases are separated by commas, and are of the
form keyword or keyword=string).

5.  Presentation.  I believe it is very important to style the
presentation of your protocols so that the simple things (probably, in the
case of DialNet, a simple text message) are kept simple, and are described
in a simple way.  If there are 40 million options for doing other things,
describe them separately.  We made this mistake in the NGP: the mandatory
parts of the protocol are VERY simple, but the simplicity is completely
obscured by all the crap in the document describing the protocol.


Please take all these comments with a grain of salt.  I am NOT trying to
design your system, but merely offering the observation that YOU'VE GOT TO
KEEP IT SIMPLE.  My only objective in offering the alternative (arm-chair)
design is to try to make that point.

∂30-Oct-77 1918 MRC	DIALnet mail formats

With the completion of the first version of the DIALnet host-host
protocols, my attention has returned to the subject of DIALnet mail.

I solicit your suggestions for the design of a mail protocol.  As of this
writing, there are two theories as to how it should be done.  In either
case, the ARPAnet way of doing things (as a command to the file transfer
protocol with the information in a mail header) has been rejected.

My concern is to have a single protocol which will be satisfactory for
both "smart" and "dumb" mailing systems.  A "dumb" mailing system is a
bare bones system which "does the job".  A "smart" mailing system has
extra hairy features.  Every mail system has to be able to be "dumb", but
if both are "smart" about something they can use it.

The first theory makes MAIL much like the ARPAnet FTP protocol.  A sample
command would be something like this:

MAIL:
TO  : MRC
FROM: MRC @ (415)-497-5505
MSG : This is a test.
.
END :

The server reads these commands (which are canonical card-image type
things) and delivers the message with whatever header is desired.  The
only thing required is the TO entry.  Everything else is optional!  The
only thing that is attractive about this design though is that it could be
written in any sort of bad environment; it is a trivial FORTRAN program
for example.

The second theory (and the one that is getting more attention around here)
is a LISP-like mail format.  The advantages to using a LISP-like syntax
are numerous, since it allows not only the removal of all sorts of quoting
and ambiguity problems, but it also is easy to parse S- expressions.  That
test message above would look like:

(MAIL (TO MRC) (FROM MRC (PHONE (415)-497-5505)) (MSG (This is a test.)))

We are wondering if any site would have difficulty in writing software
that could parse S-expressions, and if so, we would like a detailed
explanation of why it would be difficult.

Please note that this is not a protocol specification.  There are still
many other things that have yet to be decided upon.  It's only to express
the general idea.

∂31-Oct-77 1153 MOON at MIT-MC	Dialnet mail protocol

Don't dismiss the Arpanet mail protocol too lightly.  There are some good
reasons for why it is the way it is, which are distinct from the reasons
it loses.

The reason "TO:" is a command to ftp, while everything else is text in the
message, is that "TO:" is the only thing requiring interaction, since the
server has to say whether it has heard of the person in question and knows
how to send mail to her.  "TO:" has to ALSO appear in the "header",
because the recipient wants to have a way to find out who else the message
was sent to, and some of those people may not even be at the same host, so
their "TO:" commands would not have been seen by the ftp at this host.

The problem with the Arpanet mail protocol is that it is difficult and
complicated to do anything with the "header" information, other than print
it out, because it is ill-defined (which RFC 733 should fix) and not
highly-enough structured, which RFC 733 does not seem to help with.  It
sounds like what you're looking for is a scheme where the "header"
information (i.e. all the auxiliary information which is transmitted to
make more useful processing of the message possible, but is not the body
of the text) is kept strictly separate from the message text, in an
easily-processed form.  (This does not imply that it is best to make it
"commands" in an ftp-like underlying protocol.)  One problem with this is
that you are immediately committing all users of Dialnet to a considerably
hairier mail program than most Arpanet sites have now; when presenting the
message it has to take those fields that the user always wants to see, and
present them in a nicer way than their presumably easier to process for
programs form, and it has to have commands to get out the information you
want to see, but only sometimes.

The problem with transmitting the information in Lisp S-expression form is
not parsing it, that is obviously trivial (although there are a number of
lurking bugs in your example, e.g.  the parentheses in the telephone
number).  The problem is what do you parse it into?  (And possibly, why
didn't you just transmit the information in that form in the first place?)
And you are certainly not going to show the S-expressions to the user.  No
one can accuse me of being opposed to Lisp, in its [rather large but not
all-encompassing] place, but this is not a reasonable format for people to
look at for mail.

The advantages of S-expressions are that they are a fully-general way to
encode structure (except for circular and re-entrant forms), and that they
strongly discourage the use of lexical syntax (all the colons and angle
brackets and @-signs and " at "-signs of 733).  How much structure are you
planning to need, anyway?  How hairy are you trying to be?

I'm not saying that transmitting the "header" information in S-expression
form is a bad idea, but I am saying that choosing that way will commit you
to a great deal of thought about how it needs to work, and will commit the
users and implementors to hairier mail programs then they may want.
Consider how huge and bloated this could look from the standpoint of pcnet
and its microcomputers, for instance.